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(54) Vehicle sharing system and method with vehicle allocation based on travel information 



(57) A shared vehicle system includes a central fa- 
cility 12, at least one vehicle distributkxi port facility 14 
and a plurality or fleet of vehicles 16, each having a ve- 
hicle subsystem 1 8: In general, the central facility 1 2 and 
port facility 14 and the vehicle subsystems 18 commu- 
nicate in a manner to alk>w a user to enter information 
at a port facility 14. That informatk>n, including an esti- 
mated distance and time duratkxi of a trip, Is then com^ 
municated to the central facility 12, where the informa- 
tion is processed toselecta vehicle 16 from the fleetto 
alkx^ate to the user 20 at the port facility 14. Selection 
of a vehk^le 16 for allocatk)n to a user 20 may be based 
on selecting an available or soon to be available vehicle 
according to various algorithms that take into account 
the vehicles state of charge. The central facility 12 also 
communicates with the port facility 14 and the vehicle 
subsystem 18 to notify the user 20 of the selected vehi- 
cle 16, to provkle secure user access to the selected 
vehicle 16, to monitor the kx^tion and operating status - 
of vehicles in the fleet, to monitor the state of charge of 
electric vehicles and to provide other functions. The ve- 
hicles communicate with the central statk>n to notify the 
central statk)n of the PIN number of the individual at- 
tempting to use the vehicle, and of vehicle parameters 
such as state of charge and location of the vehicle. 
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Description 

BACKGROUND OF THE INVENTION 

Field of the Invention: 5 

[0CX)1] The present invention relates, generally, to 
systems and methods for sharing a fleet of vehicles 
among a plurality of users and, in preferred embodi- 
ments, to such systems and methods for sharing a fleet 10 
of electric vehicles, including systems and methods re- 
lating to allocating, tracking, securing, managing and re- . 
locating of shared vehicles and. in yet further preferred 
embodiments, to systenns and methods relating to allo- 
cating, tracking, securing, managing, relocating and- ^5 
charging of shared electric vehicles. 

Description of the Related Art: 

[0002] In most modern, industrial countries, private 20 
automobiles play an important and sometimes indispen- 
sable role as a means for transporting people within and 
beyond \oca\ areas, for example, to and from places of 
work, study or worship, on errand trips or in commercial 
activities, such as deliveries, sales visits, repair visits or 2S 
the like. As a result of these Important roles, the number 
of automobiles in and around most industrialized cities 
and neighboring regions continues to grow. The increas- 
ing numbers of automobiles results in higher occurrenc- 
es of traffic jams and higher demands for parking spac- 30 
es. 

[0003] Mass transit systems, such as busses, com- 
muter trains, subways, streetcars or the like can fulfill 
some of the transportatkxi needs of those communities 
and municipalities that have such systems. However, 35 
travel with such systems is confined to pre-set stop lo- 
cations and times, set by the route and time schedule 
of the bus, train, subway or streetcar. The prescribed 
routes and time schedules typically do not meet many 
travelers' needs or are too inconvenient for practk^l us- -«> 
age of the rr^ss transportatk>n system by some travel- 
ers. For many mass transportatk)n users, the pre-set 
stop locatkxi is far enough from their origtr^tion or des- 
tination kx^atbns that they must find additional modes - - 
of transportation to or from the pre-set stop. For exam- 45 
pie, some users drive private vehk:les to and from pre- 
set stop kx:atk>ns and park the vehicles near the stop 
locatkxis. Some nrtass transportatkxi systems even pro- 
vide vehcle parking facilities near pre-set stop locations 
for such users. so 
[0004] For example, commuter train stops and bus 
stop>s in and near some cites are often provided with 
parking lots for train users to park private vehcles. How- 
ever, vehicles in such partcing tots typically remain 
parked throughout a brge part of the day. and are driven ss 
only in the morning to bring the user to the train or bus 
stop and in the evening to take from the train or bus stop. 
Thus, while modem mass transportation systenns can 
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result in a reduced number of vehicles on the road at 
any given time, such mass transportation systems do 
not eliminate the need for private vehicles and can result 
in an inefficient use of private vehk^les. 
[0005] Accordingly, there is a need for a system and 
method for the efficient and convenient use of private 
vehk:les, such as an efficient and convenient shared ve- 
hcle system and method. Shared vehcle systems can 
provkie nrx>re flexibility than other means of public trans- 
portatbn. In a shared vehicle system, a number of ve- 
hcles are normally maintained in several designated 
parking areas. Each user is albwed to pk:k up a vehicle 
at one parking area, and return the vehicle to the parking 
area nearest to the user's destinatk)n. The user may al- 
so drive a vehicle out of a designated parking area for 
an errand and retum the vehicle to the same designated 
parking area. Shared vehicle systems that are used by 
a relatively large number of subscribers should include 
sufficient security measures to protect the vehicles from 
theft and also to protect the user from crime. 
[0006] Shared vehk:le systems must be suffk:ientty 
convenient to nrx^rvate users to emptoy the system. Ac- 
cordingly, vehicle availability within a reasor^able time of 
a user's request for a vehcle is very important to the 
success of such a system. Of course, by maintaining a 
greater number of vehicles in the fleet of shared vehi- 
cles, the availability of a vehrcle at any given time can 
be increased. However, system cost is minimized and 
vehcle-usage efficiency is maximized with smaller ve- 
hcle fleets. Accordingly, there is a need for a shared 
vehcle system that maximizes user convenience yet 
minimizes the numt>er of vehctes required in the fleet. 
[0007] In particular, by empkiying vehicles in a shared 
vehcle system or method, additional ecok>gical advan- 
tages can be achieved. Vehicles in a shared system may 
be of many types. They may be the conventior^l petro- 
leum t>ased gasoline or diesel fuel type vehicles. They 
nnay however be cleaner forms ctf propulskxi such as 
methanol or propane powered vehicles, or may be ve- 
hctes powered by hydrogen stored as a gas or metal 
hydrkie. Electric vehcles may draw energy from batter- 
ies, fuel cells, generators driven by internal combustkxi 
engines, or combinations of different energy sources. 
Electrc vehcles powered by both lead acid- and nickel 
metal hydrkJe batteries have shown much promise and 
several manufacturers have produced viable electrc ve- 
hcles employing these battery technotogies. Electric 
vehcles are a good candidate for a shared vehicle, be- 
cause they are among the cleanest and quietest forms 
of vehicle, but sharing systems and methods are in no 
way dependent on the use of an electric vehicle, and 
may be employed with a number of non electrcal or hy- 
brkj technotogies, including comnron gasoline power 
[OOOaj The use of electric powered vehicles in a fleet 
of shared vehcles, however, presents further connplex- 
rties over other alternate power vehicles, for example, 
associated with vehicle charging requirements and ve- 
hcle unavailability during charging times. 
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[0009] Electric vehicles typically require charging 
more often than the conventional vehicles require refu- 
eling. Recharging stations are not nearly as available as 
conventional petroleum motor fuels. Moreover, recharg- 
ing of an electric vehicle typically takes much nx>re time 
than refueling a conventicral vehicle. Thus, if a conven- 
tional vehicle is present at a designated parking area of 
a shared vehicle system, but does not have sufficient 
fuel to meet a user's travel needs, the vehicle can be 
quickly refueled and made available to the user. How- 
ever, even when an electric vehfcle Is idle in a designat- 
ed parking space, it is not available to a user unless it 
has a sufficient existing state of charge (SOC) to make 
the user's intended trip. Typically, an electric vehicle 
cannot be re-charged quickly enough to make the in- 
tended trip if its existing SOC is inadequate. On the other 
hand, if the user interKfs to make a short trip, the vehcle 
may be capable of making the intended trip even though 
it is not fully charged. Accordingly, there is a further need 
for a system and method for managing shared electric 
vehicles In an optimum fashion and to meet the needs 
of a maximum number of users with a minimum number 
of vehcles. 

SUMMARY OF THE DISCLOSURE 

[0010] Therefore, preferred embodiments of the 
present Inventkxi relate to shared vehicle systems and 
methods that maximize user convenience and minimize 
the nunriber of vehk:les required in the shared fleet. 
[0011] A shared vehcle system according to one pre- 
ferred embodiment of the present invention includes a 
central facility, at least one vehk^le dtstributkxi port fa- 
cility and a plurality or fleet of vehicles, each having a 
vehicle subsystem. In general, the central station and 
port facility and the vehk;le subsystems communicate in 
a manner to allow a user to enter information at a port 
facility. That information is then communk:ated-to.the 
central facility, where the informatk>n Is processed to se- 
lect a vehicle from the fleet for allocation to the user at 
the port facility. The central statkxi communicates with 
the port facility and the vehcle subsystem, according to 
various embodiments described below, to notify the user 
of the selected vehcle, to provide secure user access 
to the selected vehicle, to monitor the location and op- 
erating status of vehicles in the fleet, to monitor the state 
of charge of electric vehicles and to provide other func- 
tions described below. 

[001 2] According to one aspect of the invention, allo- 
cation of shared vehicles to users is based, at least in 
part, on travel Information received from the users. By 
alkylating vehk:les based on travel Informatkxi the effi- 
cient usage of vehicles and user convenience, can be . 
optimized, for example, to maximize vehicle availability . 
and minimize vehicle downtime. A/Vhile varbus embod- 
iments related to this aspect of the invention may env 
ploy any form of shared vehicle, according to further em- 
bodiments of the present invention, vehcle sharing sys- 



tems and methods employing electrk: vehicles in the 
shared fleet and the alkx^tion of electric vehicles to us- 
ers is managed to maximize vehk:le availability and min- 
imize vehk;le downtime, taking Into account the state of 
s charge of a veh k;le and/or the charging rate of a vehicle. 
[0013] According to another aspect of the inventkxi, 
a shared vehcle system or method provkJes controlled 
or secured access to and/or enablement of the shared 
vehk;les. In preferred emtxxilments, user identiflcatkxi 
10 informatbn Is provided to a vehk:le that has been alk>- 
cated to a user and such information must match infor- 
maton entered by the user in a user interface devce 
installed on the vehicle, before the user is allowed ac- 
cess to the vehkjie. In yet further preferred embodi- 
es ments, a user's personal identiflcatkxi number PIN must 
be entered by the user in a second interface devk:e in- 
stalled on the vehk:le and must match an expected PIN, 
before the vehicle is enabled for operation. 
[0014] According to yet another aspect of the inven- 
tion, a shared vehrcle system and method involves alk)- 
cating vehicles from a group of available vehicles and 
returning vehcles to the group upon detectkxi of a park- 
ing state while the vehk:le is located at a port. A port is 
a vehcle staging area where vehk;les n^y be parked 
prk>r to being alkx:ated to a user. A typk:ai port contains 
a user kiosk containing a computer terminal for interact- 
ing with the shared vehicle system. Throught this dis- 
ctosure the term "kiosk" will be used to mean a kk>sk 
with a user terminal. The terms kosk arxJ terminal shall 
be used interchangeably herein. In preferred embodi- 
ments, the detection of a parking state is accomplished 
by, for example, the detectkxi of the setting of the vehicle 
in a parking gear, the lack of motion of a vehcle for a 
perkxj of time, the opening and/or ck>sing of a vehk;le 
door, or a combination of such events, each of which 
require no user interaction other than the typk:al actkxis 
taken to park a vehcle. 

[0015] According to yet another aspect of the inven-, 
tion, a shared vehicle system and method involves pro- 
tecting access and enabling vehicles from a remote lo- 
cation relative to the vehicles, for example, in the event 
that a user toses an kJentificatkxi code or PIN. 
[0016] According to yet another aspect of the inven- 
tion, a shared vehcle system and method involves 
tracking stored energy and/or other operational param- 
eters of vehk;les in the shared fleet In preferred embod- 
iments, vehicle parameters, such as stored energy, are 
tracked and processed for purposes of efTicient selec- 
tion and allocatkxi of vehicles to users or selection of 
vehicles for charging. 

[0017] According to yet another aspect of the inven- 
tion is that, if electrcal vehicles are enrpk>yed within a 
shared vehkile system, the electrk^al vehk:les are alto- 
cated to users based on the state of charge (SOC) of 
the vehcles, in additkxi to vehrcle kx:atbn, user travel 
inf ormatbn and statistcal analysis of vehk:le usage. Ac- 
cording to a further advantage of preferred embodi- 
ments, vehcles are allocated from a defined vehicle 
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search group (VSG) of a port facility. A vehicle search 
group is defined as the set of vehicles that may be hIIch 
cated to a user. A vehicle search group is determined 
by deciding what time period is acceptable as a vehicle 
search depth time, that is how long a predefined wait is s 
acceptable before a vehicle becomes available. The ve- 
hicle search group then is ascertained by determining 
which vehicles will be available at the end of the prede- 
fined wailing period. Vehicles within the vehicle search 
group of a port facility Include vehicles that are due to 
arrive at the port facility within the predefined period of 
time or electric vehicles that are due to become suffi- 
ciently charged at the port facility within a predefined 
period of Wme, minus the vehicles within the port that 
have been allocated for departing trips or are scheduled ^ ^ 
for transport to another port facility. 
[0018] In one preferred embodiment that includes 
electrical vehicles within the shared vehicle group, a us- 
er is allocated a vehicle having the highest SOC within 
a vehicle search group of vehicles having sufficient SOC 
to meet a user's needs. In another preferred embodi- 
ment, a user is allocated a vehicle having the second 
highest (or Ntti highest) SOC within a vehicle search 
group of vehicles havirtg sufficient SOC to meet the us- 
er's needs, such that the highest (or N-1 highest) SOC 2S 
vehicles may be reserved for users having travel needs 
which requiring a higher SOCS: In yet another preferred ~ 
embodiment, the system or method has the ability to ak 
locate the highest or Nth highest SOC vehicle, depend- 
ing upon other criteria, such as the ttnne of day or day of 30 
the week. Thus, for a certain time period of the day and/ 
or day of the week (for example, between 7:00 a.m. and 
9:00 a.m. on Monday through Frklay) the system or 
method may allocate the highest SOC vehicle in the ve- 
hicle search group is alkx^ated to a user, while at other 3S 
times of the day and/or days of the week, the Nth highest 
SOC vehicle is allocated to a user. 
[0019] According to a further, aspect of the.present in- 
vention, a shared vehicle system and method involves 
transporting or rekx:ating vehicles from one area or port 40 
having a surplus of vehicles to another area or port hav- 
ing a shortage of. vehicles. Vehicles may also be trans- 
ported to effectively use storage space for the parking ^ 
of the vehicles. According to yet a further aspect of the 
present invent kxi, a shared vehicle system and method ^ 
involves a vehicle carrier for carrying a first vehicle with 
a second vehicle, for example, for rekx:atlng the first 
and/or second vehicle. 

[0020] The above and other aspects, features, and 
advantages of the present Invention, will become appar- so 
ent from the foltowing descriptkxi when taken in con- 
juncton with the accompanying drawings in whch pre- 
ferred embodiments ofthe present Invention.are shown 
by way of illustrative example. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021] Referring nowtothe drawings in which like ref- 
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erence numbers represent corresponding parts 
throughout: 

Fig. 1 is a schematic diagram representation of a 
vehk;le sharing system according to a preferred em- 
bodiment of the present Invention; 
Fig. 2 is a flow chart representation of steps carried 
out to request, select and allocate a vehicle, accord- 
ing to embodiments of the present invention; 
Fig. 3 is a flow chart representation of steps carried 
out for secure access and for enabling vehk:les in 
a fleet of shared vehicles according to embodi- 
ments of the present invention; 
Fig. 4 is a flow chart representation of steps carried 
out for vehicle trips according to embodiments of 
the present invention; 

Fig. 5 is a schematk: perspective view of a vehicle 
carrier according to an embodiment of the present 
invention; 

Fig. 6 is a schematk: perspective view of a vehicle 
distributon port facility according to an embodiment 
of the present inventkxi. 

Fig. 7 is a generalized block diagram representatkxi 
of a computer sut>system in a port facility according 
to an emlxxiiment of the present Inventbn; 
Fig. 8 is a schematk: perspective view of a vehicle 
. distributkxi port facility according to another em- 
bodiment of the present Invention; 
Fig. 9 is a generalized block d'agram representatkxi 
of a central facility according to an embodiment of 
the present invention; 

Fig. 10 Is a generalized block diagram representa- 
tion of a vehicle subsystem according to an embod- 
iment of the present invention; 
Fig. 1 1 is a graph of the state of charge of a vehicle 
battery versus charge time curve; and 
Fig. 1 2 Is an illustration of a transfer of vehicles be- 
tween ports; 

Fig. 1 3 is an illustration of a preferred embodiment's 
mounting of a kJentlfication card reader and a PIN 
entry console; 

Fig. 1 4 is a bkx:k diagram illustrating a central office 
computer system and the subsystem kk>sk comput- 
ers linked to the central office computer system 
through the Internet; and 

Fig. 1 5 is a flow diagram of the process when a user 
seeks a shared vehcle and interacts with a kk>sk 
computer. 

DESCRIPTION OF THE REFERRED Ef^BODIMENT 

[0022] In the foltowing descriptkxi of preferred em- 
bodiments, reference. is. nnade to the. accompanying . 
drawings, .whk:h form a part hereof, and in whk;h is 
shown by way of illustration a specific embodiment in 
which the inventton may be practced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural changes may be nnade without departing from the 
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scope of the preferred embodiments of the present in- 
vention. 

[0023] The present invention relates, generally, to 
systems and methods for sharing a fleet of vehicles 
among a plurality of users, and various aspects of such 
systems and methods including optimizing vehicle allo- 
cation, vehicle tracking, security, and charging and man- 
aging of shared electric vehicles. As discussed above, 
in a shared vehicle system, a number of vehicles are 
normally maintained in several designated parking are- 
as. Each user is allowed to pick up a vehcte at one park- 
ing area, and return the vehicle to the parking area nearr 
est to the user's destination or return the vehicle to the 
same designated parking area 
[0024] To successfully attract people to subscribe and > 
become users of a shared vehicle system, the system 
must be sufficiently convenient and inexpensive. More 
partcularly, users should be able to pk;k up a vehk:le at 
a convenient location and with minimal or no waiting 
time. The system should be easy and inexpensive for 
the user and cost effective for the system administrator 
to operate. To have minimal environmental impact, the 
system should be capable of addressing the . above 
needs and employing clean means of transportation, 
such as electric powered vehicles, as its prinr^ry shared 
vehicle. 

[0025] Preferred embodiments of the present inven- 
tion relate to shared vehicle systems and methods 
whch address the above-described needs and whk:h 
address additional needs and provide additional advan- 
tages discussed bek>w. As will become apparent from 
the discussion betow some embodiments pertain only 
to sharing systems containing at least some electrical 
vehicles. Those embodiments of the inventksn relate to 
charging or state of charge (SOC) of electric vehicles 
and may be implemented with or without various other 
aspects relating to, for example, vehk:le allocation, 
tracking, and securing: Similarly, embodiments of the in- 
vention relating to vehicle alkx:ation aspects may be im- 
plemented with or without varbus other aspects such 
as vehicle charging, tracking and securing, and embod- 
iments relating to vehcle securing may be implemented 
with or without other aspects such as vehicle tracking, 
alkx3tkxi or charging. 

[0026] A schematic representation of a shared veh cle 
system 10 according to a preferred embodiment of the 
present invent kxi is shown in Fig. 1. A system 10 ac- 
cording to the Fig. 1 embodiment includes a central fa- 
cility 12, at least one vehicle distribution port facility 14 
and a plurality or fleet of vehicles 16 (one of which is 
shown in Fig. 1), each having a vehicle subsystem 18. 
In general, the central statkxi and port facility arKJ the 
vehicle sut>systems communrcate in a manner to allow- 
a user 20 to enter information at a port facility 14. That 
information is then communicated to the central facility 
12, where the information is processed to select a vehi- 
cle from the fleet to allocate to the user at the port facility 
14. The central station 12 communicates with thff port 



facility 14 and the vehicle subsystem IB, according to 
varkDus embodiments described betow, to notify the user 
of the selected vehicle, to provkJe secure user access 
to the selected vehcle, to nrxxiitor the kx^atkxi and op- 
s erating status of vehcles in the fleet, to monitor the state 
of charge of electrk: vehicles and to provide other func- 
tions described bek^w. 

Selection and Allocation off Sharing Systems 
10 Containing Electric Vehksles: 

[0027] According to one aspect of the present inven- 
tion, systems and methods for sharing electrk: vehicles 
involve selecting and alkx^ting vehk:les to users, based 

'5- on a combinatbn of factors for maximizing efficiency 
and user-convenience. Such factors may include vari- 
ous combinations of the following: the locatkxi of the ve- 
hk:les within the fleet, state of charge of the vehicles, 
the distance whch the user expects to travel, the perkxi 

20 of time that the user expects to use the vehcle, the us- 
er's expected destination, statistkral analysis of vehicle 
use patterns and the kJentity of the user, the number of 
indivkiuals waiting for vehicles , in the port, and the 
number of vehicles present in the port. 

2S [0028] A user desiring to obtain the use of a vehicle 
16 arrives at a first port facility 14 and enters a request 
for a vehk:le and other information into a computer sys- 
tem. The information may include the destination port 
or kk)sk. The information may also include the additional 

30 distance and/or time that the user expects to travel be- 
yond the normal distance and/or time to reach the des- 
tinatkxi port facility, for example, to conduct errarKte or 
other excursbns. The information may further include 
user kjentiflcatbn inf ormatkxi, for example, read from a 

3S card key 21 . snr^rt card, magnetic strip, fingerprint, ret- 
inal scan or other machine-readable method of identifi- 
cation. 

[0029] In a preferred embodiment, described with ref- 
erence to the system in Fig. 1 and the flow chart of Fig. 

^ 2, a user enters kientification information by swiping a 
card key 21 (or other machine-readable token) past a 
reader, step 22. The inforrrratkyi is received by the sys- 
tem in step 24 and, in step 26, the user enters travel 
information (such as destinatbn, added distance and/or 

45 added time) with a keyboard, touch-screen, mouse or 
other suitable user interface. In step 27 the availability 
of a vehicle is checked, and if a vehk:le is available step 
28 folk>ws. if not step 40 will be next. 
[0030] In the present preferred embodiment, the com- 

50 puter system at the port facility 14 is programmed to 
prompt the user to enter the above-noted travel infor- 
maton. upon the user registering by swiping the card 
key 21 (or other token) past the reader The computer - 
system may display destination optkxis and/or addition-^ 

55 al time or distance optwns. Thus, the display may 
prompt the user to, for example, select or cick an kxxi 
for a proposed destinatkxi port facility. In addition other 
kx>ns for selecting a proposed additkxial number of min- 
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utes or miles of expected travel beyond the route to the 
destination port may be displayed. By selecting the ad- 
ditional icons the user may infonm the system that the 
user will have an errand trip. An errand trip is a detour 
from the regular route that would be taken in traveling 
between points. For example a user of a vehicle may 
travel directly to a destination or they may take a side 
excursion for example to pay a bill or to buy a newspa- 
per. Such side excursions are errand trips. The user can 
select different icons notifying the system that, for In- 
stance an errand trip will take an additional 45 minutes 
and add an additkxial 10 miles beyond what would be 
expected If the direct route to the destination were taken 
without the errand trip. In yet further embodiments, a 
map is displayed to the user and the user is prompted 
to identify locations on the map corresponding to a des- 
tination and/or side trip kx:ations or zones. It can be very 
important to the scheduling and alkx:ation of vehicles to 
altow for excursions such as errand trips. Efficient alk> 
cation of vehcles is easier if vehk:le trips can be pre- 
dicted with greater reliability and accuracy. Emtxxii- 
ments of the vehicle sharing system and method Include 
implementatk>ns which reward users for accuracy, for 
example if the user returns the vehicle within 5 minutes 
of the planned return time the user may get an 'accurate 
return time* discount. Users may also get a discount if 
they give notice of unexpected delays. For example if 
the usersVere charged a per hour rate a user woukl be 
charged tor a whole hour if they returned a vehicle 10 
minutes late, whereas if they gave notice of their late 
return, so that the vehicle could be reallocated during 
the proper time frame, they might be charged for only a 
portkxi of an hour. Similar discounts might be given for 
accurately predicting the number of miles driven. By ac- 
curately predicting the distance to be driven the system 
could more accurately predict, at the beginning a trip, 
the state of charge (for electrical vehicles) that will be 
present when a vehk:le is returned,, thus enabling more, 
efficient allocation of vehicles and charge facilities. 
[0031] The information entered by the user at a port 
facility 14 is communicated to the central facility 12. In 
additkxi. the central facility 12 receives information ^ 
transmitted from the vehicle subsystem 16 In each ve- 
hicle 16, relating to the kx^ation, parking state, odometer 
information, state of charge SOC of the vehicle, trip time, 
and varkxjs other trip information and statistics. Based 
on the information received from the first port facility 14 
and from the vehcle subsystems 18, the central facility 
12 selects a vehcle from among the fleet to allocate to 
the user, as shown in step 28 in Fig. 2. 
[0032] To select a vehicle, a vehcle search group Is 
defined for the first port facility. The vehcle search group 
preferably includes, vehcles 16 located and pariced aX . 
the first port facility- 1 4 that are not presently allocated- 
to other users. The vehicle search group may also in- 
clude vehicles 16 expected to arrive at the first port fa- 
cility within a pre-defined time period. Vehicles sched- 
uled to leave the port for transfer to another port or oth- 



enwise can be removed from the vehicle search group, 
as can vehicles that have insufficient SOC tor the in- 
tended use. The pre-defined time perkxJ is preferably 
selected to minimize user-waiting time, yet maximize 
vehk:le usage efficiency, or minimize energy usage or 
vehicle emissions. A pre-defined time perkxJ of, for ex- 
ample, about ten minutes may be sufficient to improve 
vehicle usage efficiency, without significantly inconven- 
iencing users. 

[0033] Vehicles 16 with an Insufficient SOC to make 
the trip to the expected destlnatkxi, including any addi- 
tional distance and/or time entered by the user and an 
additkxial margin for error or unexpected travel may be 
excluded from the vehk:le search group. Thus, a deter- 
minatkxi is made of the total charge necessary to safely 
make the trip, based on the expected destinatk>n, addi- 
tional distance and/or additional time informatkxi en- 
tered by the user. The total necessary charge Is com- 
pared with the SOC informal k>n received from vehicles 
present at the port facility or otherwise within the vehicle 
search group of the first port facility. Vehicles that have 
SOCs below the total necessary charge are excluded 
from the selecton process. However, vehicles 16 which 
are in the process of being charged at the first port fa- 
cility 14 may be Included in the vehicle search group, 
provided that they will be suffk:iently charged within a 
pre-defined time perkxJ (which may be the same pre- 
defined time period as noted above or a second time 
perkxJ) as may vehk:les arriving at the port form com- 
pleted trips, or from being transported to the port. 
[0034] If a group of more than one vehcle 1 6 is in the 
vehcle search group of the first port facility and has suf- 
ficient SOC to make the requested trip, then, according 
to one embodiment of the present inventkxi, the vehicle 
with the highest SOC within the group is selected and 
alkDcated to the user. It has been found that selecting 
the higher SOC vehicles first. typk:al}y Improves the ef- 
ficiency of the charging facilities by utilizing the charger 
In its more efficient linear range between 212 and 214 
(see Fig. 11). 

[0035] However, in the event that a user enters a re- 
quest to make a long distance trip and, thus, requires a 
vehk;le having a relatively high SOC, it.woukJ be advan-. 
tageous to have a relatively high SOC veh'cle available 
for the user, without requiring the user to wait a bng pe- 
riod of time. Accordingly, In further preferred embodi- 
ments, the vehcle having the highest SOC within the 
above-defined group Is resented for the long-distance 
user and the second highest SOC vehk;le is allocated 
to other users. Of course, If the group consists of only 
one vehcle, then that vehk:le is allocated to the user, 
rather than reserving the vehcle for a further prospec- 
tive bng-distance user. - . .. 
[0036] While the above alternative embodiment refers 
to reserving the highest SOC vehk:le within the defined 
group for a prospective long-distance user, other em- 
bodiments may reserve the highest and second highest 
SOC vehicle and so forth. Moreover, different numbers 
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of vehicles may be reserved for long-distance users de- 
pending upon the time of the day or the day of the week; 
statistical or simulated use pattems, vehicle reserva- 
tions, or a variety of other factors. In preferred embodi- 
ments, statistics of users driving practices and habits at 
each port facility can be collected and analyzed to de- 
termine the optlnr^l number of vehicles which should be 
reserved for long-distance users for any given port fa- 
cility, day and time. In yet further preferred embodi- 
ments, the system and method switches between a rou- 
tine of selecting the highest SOC vehicle within the 
group and a routine of resenting one or more of the high- 
est SOC vehicles within the group for long-distance us- 
ers, based on expected usage pattems or statistical 
analysis of actual or simulated usage pattems. 
[0037] A port facility can contain a plurality of charging 
facilities 1 69 that are used to recharge the batteries of 
electrical vehicles. Typically battery/charging systems 
for electrical vehicles have a characteristic as shown in 
the SOC versus time graph 210 as shown in Fig. 11. 
Between points 212 and 21 4 on the graph, the charging 
of the battery is essentially linear. Between points 21 4 
and 216, the charging of the battery approaches 100% 
charge exponentially and therefore the amount of 
charge obtained per unit time decreases. By allocating 
vehicles with a higher state of charge to users, instead 
of merely allocatingVehicles with a sufficient charge for 
the users requested use, the vehicles within a central 
facility will tend to be used before the charge point 214 
on the graph is reached. By charging vehicles in the lin- 
ear region between 212 and 214, more effective use of 
the charging facilities is made than by charging vehicles 
in the range between 214 and 216. This method of allo- 
cating vehicles with the highest charge, however may 
be modified, as previously described, in order to provide 
vehicles for long trip use (i.e. vehicles charged between 
214 and 216 on the state of charge graph). In cases 
where vehicles for long trips are needed the vehicles 
with the second highest charge could be allocated for 
use in order to preserve the most highly charged vehicle 
for the long trip user. In cases where a greater demand 
for long trip vehicles was present, the vehicle with the 
second highest charge might also be reserved. The al- 
location of vehicles can be modified by statistical or sim- 
ulated vehicle use in order to make the most efficient 
use of charging facilities, while at the same time attempt- 
ing to accommodate the need for vehicles with high 
state of charge for long trips. 

[0038] Once a vehk:le is selected based on the above- 
noted routines, the vehicle is alkx:ated to the user and 
the particular vehicle is kientified to the user, as shown 
at step 30 in Fig. 2. The vehcle may be kientified to the 
user by identifying the kx:atk>n of„ the vehicle,, e.g.. a., 
parking space, number, ■ or by. a. number, e.g. license - 
plate, displayed on the vehk:le. If the selected vehcle is 
due to arrive at the port facility or is due to be sufficiently 
charged at the port facility within the above-noted pre- 
defined time perkxls, then the user is notified of the ex- 



pected wart time and is asked if they will wait for the 
availability of the vehicle whch will arrive at the port. In 
preferred emtxxliments, the user is provided with an op- 
tion to accept or decline, for example, by a displayed a 

5 command prompt to accept or decline the proffered ve-. 
hicle. If the user declines the vehcle. step 32, the sys- 
tem returns to an idle condition to await the next user, 
step 34. If the user accepts the vehicle, step 36, the user 
may then pick up the vehk:le at the port facility 14, step 

10 38. 

[0039] Vehicles may arrive at the port in two distinct 
ways. A vehcle may arrive at the port if the user com- 
pletes a trip and retums the vehk:le to the port. A vehicle 
may also be relocated from another locatkxi. Fig. 12 is 
an illustration of a transfer of vehk:les between ports. An 
attendant drives a first vehicle 230. A second vehicle 
234 is towed behind the first vehicle 230, attached to the 
first vehcle via a towing mechanism 236. Couplings for 
the attachment of the towing mechanism may be in- 
stalled on the front and rear of shared vehicles (e.g. 230, 
234) so that any number of like vehk;les may be con- 
nected in series for the purpose of rekx:attng them from 
one port to another The couplings installed on the ve- 
hcles nnay also be used to transport other vehicles. Fig. 
1 2 illustrates a motor scooter 240 being transported on 
the second vehicle 234. The Scooter 240 is mounted on 
a lifting mechanism 242 Other vehicles, for exarrtple a 
bcycles or motorized bk:ycle may also be transported 
in a similar manner If a port attendant tows a second 
vehrcle with a nrx>tor scooter, as shown in Fig. 1 2 then 
when the attendant has reached the destinatkxi port the 
attendant may uncouple the motor scooter arxJ ride it 
back 238 to the embarkation port, thus rekx:aling two 
vehk:Ies in one trip. The nrwtor scooter may also have a 
carrying bracket for transporting towing mechanisms 
back to the origination port atong with the attendant. 
Electronk: towing mechanisms have also been denrx^- 
• strated. Such nr^echanisnnscausevehcles behind a lead- 
vehk^le to folbw the lead vehicle through electrons 
means. Such electron c towing mechanisms however 
are still in the experimental stage, and no commercial 
systems are available. 

[0040] If no vehcles are within the vehicle search 
. group and have sufficient SOC to meet the user's needs, 
then the system determines that a vehicle may need to 
be relocated from another port facility to the first port for 
the user, as shown in step 40. In such an event, infor- 
nnatk)n is displayed to the user relating to the expected 
time of arrival of a relocated vehcle or user returned 
vehk;le, step 42, arKi is provided with an opportunity to 
accept or decline to wait for the vehicle. If the user de- 
clines, step 44. then the system retums to an idle con- 
V. dition. step 34, and awaits the- next user. If the user ac^ 
cepts the wait time, step 46, then the user waits, step 
46 until the vehicle arrives, step 50: Upon arrival of the 
vehk;le, the user is prompted to confirm the request for 
the vehicle. If the user does not confirm the request with- 
in a preset time perkxJ. for example, five miniites as 
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shown in step 52, then the system returns to an idle con- 
dition, step 34. If, however, the user timely confimns the 
request, step 54, then the user may pick up the vehicle, 
step 38. 

[0041] Vehicles may be relocated from one port facil- 
ity to another in a variety of manners. For example, an 
attendant may simply drive the vehicle from one facility 
to the other. However, the attendant performing the re- 
location would then be displaced from his original loca- 
tion. Accordingly, two attendants nnay drive two vehicles 
to from one port to the next, leave one vehicle at the 
destination port and then both attendants may return to 
their original port in the other one of the two vehicles. 
However, that process requires two attendants to trans- 
port a vehicle between facilities. Accordingly, in a pre- 
ferred embodiment, some or all of the vehicles within 
the fleet are provided with towing bar connectors and 
each port facility is provided with towing bars for con- 
necting two vehicles together. In this manner, one vehi- 
cle may be readily connected to another and towed to 
a remote port facility by a single attendant. The attend- 
ant may then disconnect the connected vehicles, leave 
one of the vehicles for the user and return to the original 
port facility with the other one of the two vehicles. Alter- 
natively a secondary vehicle, for example a motor scoot- 
er, may be secured to the second vehicle. The nrwtor 
scooter can, upon delivery of the vehicles, be used to 
transport both the attendant and the towing bar equip- 
ment thus allowing the two connected vehicles to retrain 
at the destination port while the attendant and the towing 
equipment depart. 

Controlling Access to Allocated Vehicles: 

[0042] According to another aspect of the present in- 
vention, systems and methods for sharing vehicles in- 
volves controlling access to each allocated vehicle, so 
that access is allowed only for the user to whom the ve- - 
hide had been allocated. Security measures are imple- 
mented with the use of card keys (or other suitable ma- 
chine-readable tokens) and personal identificatkxi num- 
bers (PINs) issued to each user. Thus, according to this 
aspect of the invention, a user registers at a port facility, 
such as by swiping a card key (or other.token) or by en- 
tering identification information through other suitable 
user interface means, such as described above with re- 
spect to step 22 of Fig. 2, and a vehicle is selected by 
the central facility. If the vehicle fleet includes electric 
powered vehicles, then the selection of the vehicle is 
preferably performed in accordance with the above de- 
scribed vehicle selection and allocation aspect of the in- 
vention. However, other embodiments may empk>y oth- 
er suitable selection routines; 

[0043] - Once a vehicle is selected; identified and ac- 
cepted by the user, such as described above with re- 
spect to steps 28, 30 and 36, then the user's identifica- 
Xkxx information is sent to the vehicle subsystem 18 in 
the selected vehicle from the central facility 12, as 



shown in step 56. In preferred embodiments, the infor- 
maton is encrypted for security and addressed to the 
vehkile subsystem of the selected vehk:le. Upon receipt 
of the user identification information, the vehicle subsys- 
s tern starts a counter for timing a preset time perkxj, such 
as five minutes, as shown in step 58, and stores the 
identification information in memory, as shown in step 
60. 

[0044] Meanwhile, the user walks to the vehicle, such 
10 as in step 38. With reference to the flow chart of Fig. 3. 
if the user arrives at the vehicle within the preset time 
period, such as five minutes, the user then enters iden- 
tification inforrr^ation, for example, by swiping a card key 
(or other machine-readable token) past a reader mount- 
's ed on the selected vehicle, step 62 in Fig. 3. In preferred 
embodiments, the card key (or token) is the same card 
key (or token) used during the user registratkxi at the 
port facility. If the identificatkxi information (card key or 
token) is not read by the reader within the preset time 
20 perkxl, then the user identificatkxi routine is disabled on 
the vehicle subsystem, step 64 and the vehk:le is des- 
ignated as being available for further users, step 66. 
[0045] If, on the other hand, the user's kJentification 
informatk)n (card key or token) is read within the preset 
2S time period, step 68, then the vehicle subsystem com- 
pares the stored identification informatbn received from 
the central facility with the identificatk>n informatkxi en- 
tered by the user (read by the card or token reader), as 
shown in step 70. If the tdentrfication infonmation does 
30 not match, then the user is denied access to the vehicle, 
step 72. 

[0046] If the kJentification information received from 
the central facility matches the kJentificatkxi informaton 
(card key or token) entered by the user, then the user is 

3S alk>wed access to the vehicle, as shown in step 74 and 
a counter starts timing a preset time perkxJ, such as five 
minutes, as shown tn step 76. In preferred embodi- 
^ ments, the vehicle subsystem emptoys an * electronk;." 
door lock that is controlled to selectively unlock the ve- 

40 hk;le. step 78. to altow access to the vehicle interbr. In 
addition, counters within the vehk;le subsystem are set 
and started for counting the number attempts of entering 
a personal kJentificat»n number PIN, step 80, and for. 
timing a preset time perkxJ by which a correct PIN must 

^ be entered, such as 200 seconds, step 82. 

[0047] After gaining access to the vehicle, the user 
enters the vehicle and closes the vehicle door, step 84. 
The user is provided with an opportunity to enter a PIN 
in a user interface and display devk:e mounted, for ex- 

50 ample, in the center console, dashboard or overhead 
console of the vehicle. If the user does not enter the cor- 
rect PIN within a preset number of attempts, for exam- 
ple, five attempts, as shown in step 86, or within a preset 
- time period, such as 200 seconds as shown in step 88, 

ss then the user's request for a vehicle is canceled, step 
90 and an error message is displayed on the user inter- 
face and display device, step 92. Thereafter, when the 
user leaves the vehicle, step 94, and cbses the doors. 
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the ctoors are automatically locked, step 96, and the ve- 
hicle subsystem returns to an idle state, step 98. The 
vehicle is then made available for further users, as 
shown by the connection to step 66. If, on the other 
hand, the user enters the correct PIN within the preset 
number of attempts and the preset time period, step 
100, then the vehicle subsystem enables the vehicle 
and the user may operate the vehicle, step 102. 
[0048] In one preferred embodiment both the user's 
identification data and PIN are read from a user's iden- 
tification card and communicated to the vehicle to be 
allocated to the particular user. As soon as the user's 
identification data and PIN are communicated to the ve- 
hicle to be allocated to the particular user, an authorized 
user may drive the vehicle on a trip without any further 
communication between the vehicle and the central fa- 
cility. Upon use of the proper identification card and en- 
try of a correct pin within the vehcle, the vehicle is ready 
to drive. The identification card reader 246 may be lo- 
cated on a window as shown Fig. 13. The PIN entry is 
accomplished by means of an input and display device, 
which may be mourited in a center console within the 
vehicle as shown, in Fig. 13. In another preferred errv 
bodiment, the determination of whether the entered PIN 
is correct or not is made at the central facility, for addi- 
tional security. In this case the valid pin is not sent to the 
vehicle, instead the user in the vehicle enters a PIN 
which is then sent to the central facility for validity de- 
termination. If the PIN is valid then the central facility 
sends a notification of valid PIN to the vehicle. In partic- 
ular, the central facility 12 preferably includes or oper- 
ates with a database, table, algorithm, number encoded 
on the user's identification card, or the like which asso- 
ciates each user's bentificatkxi infonmatkxi (card key or 
token) with the user's personal kientification number 
PIN. Accordingly, upon receiving the requesting user's 
identrficatkxi information, the central facility 1 2 obtains 
that user's PIN, for example, by comparing the identifi- 
cation information with corresponding data base entries 
and reading PIN information associated in a database 
with the identificatkxi informatk)n. Furthernrx>re. when 
the user enters a PIN in the user interface arid display 
device in the vehk:le, steps 86 or 100, the vehicle sub- 
system transmits the entered PIN to the central facility. 
The central facility then compares the PI N received from 
the vehk:le subsystem with the PIN retrieved from the 
database, table, algorithm, user's identificatkxi card, or 
the like. If a sufficient match exists, then the user is con- 
sidered to have entered a correct PIN. The central facil- 
ity may then send an enabling command to the vehcle, 
acknowledging that a correct PIN has been entered at 
the vehcle and the vehcle may be driven. The correct 
pin can be maintained in the vehcle subsystem 18 for 
later identification of the user and enabling of the vehi- 
cle, even if the vehcle were not in corinmuncatkxi with 
the central facility. 

[0049] Accordingly, preferred embodiments provkie 
multiple levels of security. A first level of security is pro- 



vkjed by the fact that a valid ID card is required even to 
enter the port facility. A second level of security is pro- 
vided by the requirement that a user must proffer the .. 
proper dentificatkxi at the kiosk 14 to be assigned a ve- 

5 hicle. A third level of security is provided at the vehicle 
where the user must enter valkJ identification infornra- 
tion (for example, by swiping a card key or token) to gain 
access to the vehicle. A fourth level of security is pro- 
vided by the requirement that, once the user gains ac- 

10 cess, the user must input a PI N that corresponds to the 
same userassociated with the identificatkxi informatkxi. 
Moreover, each of these entries must be made within a 
preset period of time. These multiple levels of security 
reduce the risk of unauthorized entry and unauthorized 
use or theft, of the. vehicles. Tb us, users are provkjed 
with a more secure environment within the vehicles and 
the vehicle owners and system administrators are pro- 
vkled with a reduced risk of vehcle theft or misuse. 

20 Vehicle Trip and Conditkxi Monitoring : 

[0050] In accordance with further aspects of the 
present inventkxi, after the user engages the engine as 
discussed above with respect to step 102. the user may 

25 shift into drive, step 104 of Fig. 4, to begin the user's 
requested trip. During the course of the trip, the vehicle 
subsystem monitors various parameters associated 
with the vehcle, for example, the location of the vehcle, 
the state of charge SOC of the vehcle (In electrical ve- 

30 hides) and other operatk>nal parameters such as odom- 
eter reading, speed, and actual usage or drive time, as 
shown In step 106. Information, including kx^tkxi infor- 
matkDn, SOC and other operational information, such as 
whether the vehicle is moving and rf so at what speed, 

3S whether the vehicle is charging, the odometer reading, 
the state of charge of the battery system, is preferably 
transmitted from the vehcle subsystem 1 8 to the central 
facility 12 at perkxJic or non-periodic intervals: In this 
manner, the central facility may readily track each vehi- 

40 cle in the fleet and render selection and alkx:ation de- 
term inat ens based on vehcle location and SOC infor- 
matk>n for each vehicle, as described above. Inadditron, 
the central facility may monitor the SOC of fleet vehicles 
for purposes of warning users and port facility attend- 

45 ants to re-charge a vehicle. 

[0051] The user interface and display device within 
the selected vehcle displays various information to the 
user, for exannple. usage time, or warnings relating to 
the SOC or other vehicle parameters, notices or travel 

50 informatbn sent from the central facility, as shown in 
step 108. For exannple, the central facility may send a 
warning to a vehicle, to inform the user that the SOC of 
the vehcle is tow or has experienced an unusual fluctu- 
ation: The user may be informed to return the vehcle to 

55 the nearest port or kiosk or to simply connect the vehicle 
to a charger, upon the user's scheduled return. 
[0052] The user interface and display device within 
the selected vehcle may also be used to transmit mes- 
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sages to the central facility. A group of preset messages 
such as flat tire", "vehicle inoperative* or "send help" 
may be transmitted from a user interface and display 
console within the vehicle by the user selecting which 
message to transmit to the central facility. . 
[0053] In further preferred embodiments, the vehicle 
subsystem may include or operate with a locator such 
as global positioning system (GPS), dead reckoning 
system, radio beacon triangulation system, or a variety 
of other techniques for providing tracking and route in- 
tormatkm. The user interface and display device may 
be used to display map and route information, in accord- 
ance with well known tracking and routing systems. 

Vehcle Parking and Return : 

[0054] At some point in the duratkxi of the user's trip, 
the user will stop the vehicle and place the vehcle in a 
parking gear as shown in steps 1 1 0 and 11 2. In preferred 
embodiments, ttie vehicle subsystem 18 includes a sen- 
sor system for sensing such an event. Upon sensingthat 
the transmisskxi is set in a parking state and/or the ig- 
nition or power is turned off, the vehicle subsystem 18 
transmrts a parking state signal to the central facility. 
Once the vehrcle is placed in a parking state, the vehicle 
Is turned off and disabled, as shown in step 114. until 
the user reenters the correct user kJentification and cor- 
rect PIN. If the vehcle is at a port facility however and 
the vehicle is placed in a parking state, the vehicles is 
tumed off and disabled, the user must go through the 
vehicle alkx^tk>n process again if they desire to use a 
vehicle further At the port the vehcle is retumed to the 
pool of available vehicles when it is placed in the park 
state. 

[0055] In further preferred embodiments, the vehicle 
subsystem 18 includes or operates with sensors for 
sensing the user exiting the vehcle, step 116, such as 
sensors for sensing the.driver-side door opening and/or 
closing after the vehcle is set in a parking gear. Further 
embodiments may employ other suitable sensors for 
sensing a parking conditkxi, including, but ncA limited to 
a pressure sensor for sensing presence of weight on the 
driver's seat, a sensor for sensing the setting of the park- 
ing brake, or the lack of nwtkxi for a predefined period 
of time, or combinatkxis thereof. In yet further embodi- 
ments, the user may simpty enter a notrce indk:ating that 
the vehble is parked in the user interface and display 
device in the vehicle. 

[0056] Information relating to the parked state of the 
vehicle is transmitted from the vehk:le subsystem to the 
central facility. However, further information is needed 
to determine whether the vehcle is parked and being 
retumed to aport facility. or is merely temporarily parking 
while the user is conducting an errand. Accordingly, In 
preferred embodiments, if the vehicle is in a parked 
state, then the vehicle's locatkxi is determined, as 
shown in step 118. As discussed above, any suitable 
vehicle tracking system may be employed to track and 



determine vehk;le locations, including, but not limited to, 
GPS systems, a Teletrac system (Teletrac is a trade- 
mark of Teletrac, Carlsbad California), or the like. 
[0057] It the vehicle is determined to be within a port 
5 facility when placed in a parked condition, then the ve- 
hicle subsystem is controlled to lock the vehicle doors 
within a preset time period, for example, 30 seconds, 
after the last vehicle door is ctosed, step 120. The vehi- 
cle subsystem then returns to the kJte conditon, step 
122, and awaits alkx^tion to a further user. 
[0058] If the vehicle is determined to be outside of a 
port facility when placed in a parked corvdition, then the 
vehk^le subsystem is controlled to lock the vehicle doors 
and disable the vehk:le within a preset time period, for 
example, 30 seconds, step 1 24. The vehk:le subsystem 
also may be controlled to kxk the vehicle doors after a 
door has been opened or after the ignitkxi has been 
tumed off. However, instead of retuming to kjle condi- 
tion, the vehicle subsystem remains prograrrvned to al- 
k)w access and the enabling of the vehicle to the user 
with the same user identificatkxi and PIN, as shown in 
step 126. In this regard, when the user returns to the 
vehk:le, the user may input the same identification data 
(for example, by swiping the same card or token) there- 
by entering the same PIN that was previously entered 
by the user or sent to the vehicle via the central system, 
as shown in step 1 28. Thereafter,, the process of com- 
paring identiticatk>n informatkx) and processing PIN in- 
formation is carried out simitar to that described above 
with respect to Fig. 3, beginning at step 70. 
[0059] Thus, in accordar)ce with a further aspect of 
the present inventkxi. the parking state of each vehicle 
1 6 is sensed and a determination is made as to whether 
the vehk:le has been retumed or is merely temporarily 
parked during a user's trip. The kientificatbn information 
and PIN data required to access the vehicle rennain the 
same, unless it is determined that the vehk:le has been 
retumed and parked at a port facility. Accordingly, a ve- 
hcle nnay t>e automatically reallocated to another user 
upon the determinatkxi that the vehkile has been parked 
and returned to that facility. 



45 [0060] According to further aspects of the present in- 
vention, safety measures are implemented to address 
situations in whch a legitimate user inadvertently enters 
the wrong PIN more than the allowed number of at- 
tempts, fails to enter the information within the preset 

50 time perkxi, loses a card key or kx^ks the card key inskie 
of the vehicle. In the event that a legitimate user is in- 
advertently denied access to or enablement ol a vehcle, 
. then the usermay contact the central facility by suitable . 
means, including, butnotltmited to, telephone, portable 

5S Internet connection, or other communcatkxi device. 
Upon verification of the user's identity, the central facility 
transmits a command to the user's vehicle to instruct the 
vehcle subsystem to unlock and enable the vehrcle for 
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the user If the user is at a remote location from the ve- 
hicle, for instance at a public telephone, the enablement 
comnrtand may have a delayed enabling effect in order 
to allow the user to return to the vehicle before It is en- 
abled.. 5 
[0061] User identity may be verified, for example, by 
requesting that the user provide certain personalized in- 
formation for comparison with such information ob- 
tained from the user when the user originally subscribed 
to the system. In addition, the location of the vehicle may io 
be determined, as noted above, and nnay be compared 
with the expected vehicle location, based on the travel 
information entered by the user upon requesting the ve- 
hicle. 

[0062] In addition the vehicle possesses a Mail safe' 
operations mode. Once a vehicle is checked out by a 
user ft will continue to operate for the balance of the us- 
er's trip, even if the communications unit which main- 
tains communication with the central facility should fail, 
or should the central facility cease function for any rea- 20 
son. Thus there is no condition where loss of communi- 
cations between the central facility and the vehicle will 
cause the vehicle to become disabled. 
[0063] The vehicle may also be disabled in some cir- 
cumstances, such as when the vehicle is reported as 
stolen, or when proper authorities seek to immobilize the 
vehicle. Ihe vehicle may also be enabled in an emer- 
gency, for instar^e if the vehicle is in danger of being 
damaged if it is not nrx>ved, such as a spreading fire in 
a nearby facility. 30 

Vehcle Rekx:atkxi : 

[0064] As discussed atx3ve, in preferred embodi- 
ments, vehicles may be relocated from one port facility 3S 
to another, to meet user demands or to relieve a facility 
of an oversupply of vehicles. Also as discussed above, 
in a preferred embodiment, some or all of the vehkiles^ 
within the fleet are provided with towing bar connectors 
and each port facility is provided with towing bars for ^ 
connecting two or nrx>re vehk^les together. In this man- 
ner, one vehkile may be readily connected to another 
and towed to a remote port facility by a single attendant. 
The attendant may then disconnect the connected ve-. 
hides, leave one of the vehicles for the user and return ^ 
to the original port facility with the other one of the two 
vehicles, or on a vehcle, for example a motor scooter, 
mounted on one of the vehk;les. 
[0065] The ability to connect vehicles, rekx^ate the 
connected vehcles and disconnect the vehicles at the so 
relocation in a time efficient manner requires a tow bar 
and connection system that can be operated quckly and 
easily. Accordingly in preferred embodiments some or- 
al! of the fleet vehcles are provided with tow bar con- 
nectors and each port facility is provkJed with at least ss 
one tow bar designed for quick and easy connectkxi to 
the vehk:les. The relocatkxi aspect becomes more com- 
plex, however, when the fleet of vehicles includes a va- 



riety of different types of vehicles, such as four-wheel 
vehk;les, two-wheel vehk;les, and/or three-wheel vehi- 
cles. In such embodiments, it is preferred that a tow or 
carrier mechanism be provided to allow various types of 
vehk;les to be. towed or carried by other fleet vehk:les 
from one port facility to another. 
[0066] Thus, for example. Fig. 5 shows an example 
of a carrier bracket 1 30 for connectkxi to a standard tow 
bar receptacle on the rear of a vehk:le, and whch is con- 
figured to carry a further vehk^le, such as a two-wheeled 
or three-wheeled vehicle. More particularly, the bracket 
130 includes a first 'L'-shaped member 132 and a sec- 
ond, snnaller V-shaped member 134 coupled in a slid- 
ing relationship with the first member 132. Each "L" 
shaped member 1 32 and 1 34 includes a vertical leg and 
a horizontal leg. The vertical leg of the member 1 34 is 
coupled, by brackets 1 36 to the vertk:al leg of member 
1 32 and is slklable in the directkx> of arrow 1 38, akxig 
the vertical dimenson. The vertical leg of member 134 
is connected to a flexible band 1 40. The opposite end 
of the strap 140 is wound around a spool or reel 142. 
[0067] In operatkxi. the horizontal leg 1 44 of member 
1 32 is shaped to fit within and connect to the standard 
tow bar receptacle on the back of at least some of the 
fleet vehicles. The horizontal leg 146 of memt>er 1 34 in- 
cludes a key or pin receptacle aperture 146 and is con- 
figured to couple to an inverted "U'-shaped bracket 
rrwunted to the underside of the vehcle 1 6' to be can-ied. 
For exarr^le, Fig 5 shows an inverted 'U '-shaped 
bracket 150 mounted to the underskie of a motorized 
two-wheeled vehcle. The bracket 150 defines a 'U'- 
shaped opening for receiving the horizontal leg 146 of 
the member 134. Apertures 152 in the bracket 150 are 
positioned to align with aperture 148, upon the bracket 
150 receiving the horizontal leg 146 of member 134. 
With the apertures aligned, the pin 154 may be inserted 
through the bracket 150 and leg 148. to secure the ve- 
hcle 1 6' to the carrier bracket 1 30. Accordingly the ve- 
hcle 16* may be canied by a vehcle 16, by simply con- 
necting the teg 144 to the standard tow-bar receptacle 
of a vehcle 16, then placing the vehicle 16' on the hor- 
izontal leg 1 46 and inserting the pin 1 54 through the ap- 
ertures 146 and 152. Finally, the vehcle 16* nnay then 
be lifted by rotating the spool or reel 1 42 to take up some 
of the flexible band 1 40 and, thereby, draw the bracket 
1 34 in the vertcally upward directkxi. The raising and 
bwering mechanism just described may be replaced by 
a variety of lifting mechanisms known in the art. For ex- 
ample the lifting mechanism provkled may be a hydrau- 
lic, pneumatc, rack and pinion, scissors and screw, or 
other mechanisms known in the art. 
[0066] After relocating the vehcles 1 6 and 1 6', the ve- 
hcle 1 6' may be detached f rom-the bracket 1 30 by re-^ 
nrxwing pin 54 and lifting the vehcle 16' off off the hori- 
zontal leg 146. If needed, the member 1 34 may be tow- 
ered by unwinding the spool or reel 142 to assist in re- 
rTX>ving the vehicle 16'. The lifting mechanism can er^a- 
bte someone to transport a vehicle that would otherwise 
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be too heavy tor an individual to lift onto a vehicle carrier 
without the lifting facility. 

[0069] In preferred embodiments, many of the func- 
tions of the port facility computer system, the central fa- 
cility and the vehicle subsystem described above with 
respect to the flow charts of Figs. 2-4 can be implement- 
ed by programmable computers and processors. Em- 
bodiments of programnnable computer or processor 
based facilities and vehicle subsystems are described 
below with reference to Figs. 6 - 10 as representative 
examples. However, it will be understood that the sys- 
tem and methods according to the present invention . 
may be implemented in various combinations of hard- 
ware and software configurations and are not limited to 
specific example configurations described herein. 

Port Facility : 

[0070] In preferred embodiments, the system 10 in 
Fig. 1 includes a plurality of port facility 14 located in 
geographically TemoXe locations relative to each other, 
for example, at locations convenient for a large number 
of potential users, such as near train or bus stations, 
campuses, office parks, shopping areas or the like. Two 
examples of vehicle distributkxi port facility 14 are 
shown in Figs. 6 and 8, respectively. In the example em- 
bodiments of Figs. 6 and 8, the vehicle distribution port 
1 0 facility includes parking spaces 1 56 for parking a plu- 
rality of vehicles 16. In addition, the distributkxi port 10 
includes a computer subsystem 158 typically kx:ated at 
a kiosk 14 to facilitate user interaction. Fig. 7 shows a 
generalized bkxk diagram representatk>n of the com- 
puter subsystem 158, which includes a computer 160, 
a display and user interface devk:e 162, and a commu- 
nicatkxis interface 164 for communicatnn with the cen- 
tral facility 12. The communications interface 164 may 
be, for example, a satellite, radio frequency RF or other 
wireless link, in whrch case, the interface 164 wouW in- 
clude a transmitter/receiver. In a preferred embodiment 
of the inventkxi. the interface 164 between the central 
offk:e facility and the subsystem 1 58 may comprise a 
hard wired connection, such as through computers 
linked to the Internet. Such a preferred embodiment is 
illustrated in Fig. 14..ln Fig.14the user's interface to the . 
system is a kk>sk containing a computer, display screen, 
and one or nrx>re input devk:es such as a card reader 
and a keyboard and touch screen. A kiosk computer 250 
senses as a web client connected to the Intemet. The 
system control computer 254 senses several functnns, 
for example as the registratbn web-server 256 process 
computer, it also provides a rrKxiitoring and control proc- 
ess 264 for the system. The registratkxi web-server 256 
serves the kk>sk 250 computer web clients. The regis- 
tration web-server 256 also altows access to the regis- 
tration web-sen^er 256 by other computers connected 
to the Intemet, Having a web connectkxi not only sim- 
plifies the connect kxi of the kk>sk 250 computer(s) to 
the system by albwing the kk>sk web clients 250 to be 



kx3ted anywhere there is a ready connectkxi to the In- 
temet, it alk>ws access to the vehcle sharing system 
from other Intemet connected computers. This is valu- 
able for users of the system because they nnay access 
the systemTemotely, for example to make reservations 
for shared vehicles, to determine if vehicles are availa- 
ble at a port, to determine how bng a wait there is for a 
vehcle, to apply for membership in the vehk;le sharing 
system or for other reasons. 

[0071] The registratk>n web-sen^er 256 also interfac- 
es with a database 258. The database 258 contains user 
data 266, in whch is kept a record off user informaton 
and statistcs, such as the time and date that the user 
used the system, the user ID, the destinatkxi of the past 
trip, vehicle information, port information, as welt as the 
time and distance estimates entered by the user for the 
past trips. These statistics can be used to predict vehicle 
usage, for example rf a user makes a reservation ffor a 
shared vehicle. The database 258 may contain a user 
request database 268, in which user requests for vehi- 
cles and allocation informatkxi of the vehicle may be 
kept, as well as a wart request data 262. The wait re- 
quest data 262 may contain information about vehicle 
requests that cannot be immediately filled, for lack of a 
vehcle or in the case that the vehk:le is. for instance an 
electrk:al vehicle, lack of a vehicle with sufficient battery 
charge. The wait request data 262 may contain such in^ 
formation as the time and date that the user used the 
system, the user ID. the destinatkxi of the past trip re- 
quested as welt as the time and distance estimates en- 
tered by the user for the trip requested. In one embodi- 
ment the wait request data may be on a separate com- 
puter and may be accessed by a user having the proper 
database permisskxis 260. Safeguarding the wait re- 
quest database 262 is important because the monitoring 
and control process 264 within the system control com- 
puter 254 uses the wait request data 262 to allocate ve- 
hicles to users who are waiting for vehk;les. 
[0072] Fig. 15 is a flow diagram of the process when 
a user seeks a shared vehcle. As the user approaches 
the kiosk the system is kJling. bkx:k 270. The user then 
swipes their identrficaton card at the kiosk card reader - 
as in bkx:k 272. The card read by the kiosk card reader 
is the same card as used at the vehicle to gain entry, . 
and is also the same card used to gain access to the 
kk>sk area. The kk>sk computer then accesses the reg- 
istratkxi web server in bkx:k 274. When communicatkxi 
has been established between the registratkxi web 
server 256 and the kiosk web client 250 computer. bkx:k 
276 is executed. In bkx:k 276 user kJentification infor- 
matbn. whch has been obtained from the identificatkxi 
card, akxig with a kk>sk ID kientifytng the transmitting 
kbsk, is sent to the registratkxi web server. Next in bkx:k^ - 
278 the registration web server 256 compares the user 
ID received from the kiosk web client 250 computer to 
the active user list to see if the user is an authorized 
user. If the user ID is invalkj. bkx:k 282. the user is told, 
in block 283, that their user I D is not valid and the system 
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returns to the idle state in block 270. tf the User ID is 
valid, block 2B0. then the reglstratkxi web server 256 
collects the user request information in block 284. The 
user request information consists of information such as 
vehicle destination, estimated. time of the trip, and esti- s 
mated distance of the trip. When the user information 
has been collected the registratk>n web server 256 que- 
ries the shared system database, in bkx;k 286, in order 
to satisfy the request. In bkx;k 288 the registration web 
sen/er 250 selects an available vehicle from the data- /o 
base 258 to satisfy the user request. In bkxk 290 the 
user is asked if they accept or decline the offered vehi- 
cle. If the user declines the vehicle, bkx^k 294, the reg- 
istratkxi web server 256 disconnects as seen in block 
296. If the user accepts the vehicle, in. block 292, the . '5 
reglstratkxi web server 256 stores the trip request data 
in the shared vehicle database in bbck 298. Finally In 
block 300 a computer control process polls the vehcle 
request database and processes the request. 
[0073] The computer subsystem 1 58 is preferably dis- 20 
posed in a well lit and highly visible locaton and, more 
preferably, Is also housed within a bulbing or enck)sed 
structure 166 (as shown in Fig. 2), to which access is 
controlled for user security. Access may be controlled 
by an attendant stationed at the port facility 14 or by a 2S 
starxjard lock and key system, wherein a key to the door 
168 is issued to each user. However, in preferred em- 
bodiments, the door kxk is controlled by a card key entry 
system and each user is issued a card key comprising 
a card on which magnetic, optcal or other nr^achine- 30 
readable data is recorded. In such systerrts, the en- 
closed structure 1 66 is provkJed with an electronk; door 
lock 170 (Fig. 7) and a card reader 172 disposed in a 
user accessible location outside of the structure 1 66, for 
example, adjacent the door 166. 3S 
[0074] To gain entry to the structure 1 66, a user must 
swipe or insert the user's card key past or in the card 
reader 172, to allow data from the card to be read and 
communk^ated to the computer 160. The computer 160 
is programmed to process the user I D and. provided us- ^ 
er ID is in the database of currently valid users, controls 
the electronic door lock 1 70 to unlock the door 1 68 and 
altow the user to enter the structure 166. For example; 
the data may comprise a user kientification code or an .~ 
expiration date code and the computer 1 60 may be pro- 45 
grammed to compare user identificatk^n code with a da- 
tabase of valkJ user identificatkxi codes or compare the 
expiration date code with the current date. Thus, the 
computer 160 may be programmed to unlock the door 
1 72, only if the user identification code is valid or an ex- so 
pi ration date has not passed. 

[0075] Once the user has entered the structure 166, 
the user will have access to the port facility display and 
user interface devce 162. The display and user inter- 
Xbcq devce 162 may comprise any suitable display in- ss 
eluding, but not limited to, a cathode ray tube CFTT dis- 
play. Ik^uki crystal display LCD or the like, and any suit- 
able user interface, including, but not limited to, a touch- 



screen integrated with the display, a keyboard, a mouse, 
a joy stkik or the like. For user convenience, a CFTT dis- 
play with a touch -screen user interface is preferred. 
[0076] The display and user interface 162 is provkjed 
to display instructions, prompts and information to the 
user and to albw the user to enter information, such as 
travel information and/or identrficatkxi information, from 
the users ID card, for processing by the computer 160 
or communication to the central facility 12. For added 
security, a second card reader (also represented by box 
172 in Fig. 7) may be disposed within the structure 166, 
adjacent the display and user interface 162, for the user 
to enter card key data to initiate or continue interactkxi 
with the display and user interface 162. As described 
above, travel information and/or identificatk>n infomna- 
tlon entered by a user at a port facility 14 is communi- 
cated to the central facility 1 2 and is used by the central 
facility to select a vehk;le for the user to pick up at the 
port facility 14. 

[0077] In the Fig. 8 example, the vehicle parking spac- 
es 156 are kxated within an enclosed structure, such 
as a bulbing 174 having a gate or passage 176 through 
which vehk;les may enter and exit, for added vehcle se- 
curity. In addition, the Fig. 8 example includes tracks 178 
for automated nrtovement of vehk^les between parking 
spaces 156 and the gate or passage 176. Thus, for ex- 
ample, a vehicle selected for a user 20 at the port facility 
may be automatbally moved from a parking space 156 
and delivered to the gate 176 for pick up by the user. 
Similarly, upon completkxi of a trip or upon delivery of 
a vehk:le to the gate 176 of the port facility, the vehicle 
may be autonratk:ally moved from the gate to a parking 
space 156. 

[007B] In preferred embodiments, the vehicle fleet in- 
cludes or is composed entirely of electrk: powered ve- 
hcles. Accordingly, each of the vehicle distributkyi port 
facility examples shown in Figs. 6 and 8 includes vehicle 
charging devices kx^ted adjacent at least some of the 
parking spaces. In the Fig. 6 example, the charging units 
may include automated connectors, for automatk:alty 
connecting and disconnecting from vehicles in the park- 
ing spaces 156. 

Central facility : ...... 

[0079] A generalized bkxk diagram representation of 
an example central facility 12 is shown in Fig. 9. The 
central facility 12 in Fig. 9 includes a computer 180 with 
an Internet connectkxi 13, programmed for processing 
user travel and/or kientifk:ation informatkxi received 
from vehicle distributbn port facility and selecting vehi- 
cles for users, based on the received informatkyi. The 
central facility 1 2 also includes a transmitter/receiver 
unit 182 for communk:ation with the vehicle subsystems ^ 
18, for example using a satellite communcation link, an 
RF link or c^her suitable wireless link. As described 
above, the central facility 1 2 is also coupled for commu- 
n cat ion with the computer subsystems 1 58 at the vehi- 
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cle distribution port facilrty. That communication link may 
also be made through the transmitter/receiver unit 182 
or, alternatrvely, through a separate communications 
link such as a hard wired link. 

[0080] As discussed above, the computer 1 80 is pref- . s 
erably programmed to conduct vehcle tracking rou- 
tines, for example, in accordance with standard vehicle 
tracking and communicatkx) software, including, but not 
limited to a Teletrac system (Teletrac is a trademark of 
Teletrac, Carlsbad California). Accordingly, the central io 
office facility 12 also includes display devk:es 184, for 
providing a system administrator with visual information 
regarding the locatkxi and also regarding vark>us rrKxi- 
rtored operational conditions of vehk;les in the fleet, and 
an input devk:e 186, such as a keyboard, rrxjuse, or the 
like, for altowing the system administrator to input in- 
structions and data. Preferably, the central office facility 
is located in a secure environment, such as a secure 
office building, where data relating to user identification 
codes and other sensitive or private information may be 20 
maintained in a secure nr^nner. 

Vehk:le Subsystem : 

[0081] As described above, each vehcle 16 in the 
fleet is provided with a vehk;le subsystem 18 for conv 
muncating with the central office facility 1 2 and for per- 
forming a variety of other functions, depending upon the 
embodiment of the invention. A generalized block dia- 
gram representatkxi of a vehicle subsystem 1 8 is shown 30 
in Fig. 10. Each vehcle subsystem 18 includes a pro- 
grammable processor or computer 188 for processing 
information and controlling the operatbn of other com- 
ponents of the subsystem 18. The vehicle subsystem 
1 8 also irKludes a transmitter/receiver unit 1 90 for wire- 3S 
less communk^tkxi with the central facility, as dis- 
cussed above. The vehicle subsystem also includes a 

display arxj user interface unit 1 92. - 

[0082] In embodiments in which the vehicles within 
the fleet are enclosed vehicles, such as those shown in 4o 
Figs. 1 , 6 and 8, then the display and user interface unit 
1 92 is disposed within the enclosed interior of the vehi- 
cle, in a convenient kx^ation for access by a vehicle user, 
such as on the center console, dashboard or overhead 
console. 45 
[0083] The vehk:le subsystem for enclosed vehicles 
also includes a card reader 196 mounted for access by 
a user from outskJe of the vehk;le. Thus, for example. 
Fig. 6 shows a card reader 1 96 rrx^unted to the inskJe 
of the passenger window, behind the driver's side door. 50 
To gain access to the vehk:le selected for a user, the 
user must swipe the card key past the card reader, to 
allow the data recorded on the card to be read..The data . ^ 
read by the card reader 1 96 is provided to the processor - 
188 for comparison with data received from the central 55 
facility, through transmitter/receiver unit 190. The proc- 
essor 188 is programmed to control an electronic door 
kx;k 1 98 to unlock one or more vehcle doors and allow 



access to the vehk;le interior, upon a sufficient match 
between the compared data. 

[0084] Once the vehcle door is unkxked, the user 
may enter the vehicle and gain access to display and 
user interface 192, The processor 188. is programmed 
to operate with the display and user interface 192 to dis- 
play instructions to the user and to receive data input by 
the user, including a personal identification number PIN. 
The processor 188 is further programmed to enable or 
disable the operat»n of the vehcle by provcling an en- 
able or disable signal 200 to an operatkxi-crrtcal ele- 
ment, based on the validity of the PIN entered by the 
user The enable or disable signal nnay be used to con- 
trol a suitable device for enabling or disabling any oper- 
ation-critcal element of the vehicle, including, but not 
limited to. the vehcle ignitkxi system or fuel line (for in- 
ternal combustion powered vehcles), the battery power 
source, or the like. Devices whch respond to enable or 
disable signals for enabling or disabling ignition sys- 
tems, fuel lines, battery power sources or the like are 
well krK>wn in the vehicle security fiekj. In the case of an 
electrc vehicle, for example, a disable signal woukJ be 
activated by the vehicle being in a charging state. This 
would prevent the vehicle from being driven while it was 
connected to the charging facilities, thus eliminating 
damage that could be caused if the vehcle were acci- 
dentally driven white still connected to the chargrig fa- 
cilities. 

[0085] In further embodiments of the invention, the 
vehcle subsystem includes one or more parking state 
sensors 202, for sensing the parking state of the vehicle. 
As discussed above, the parking state of a vehicle may 
be sensed in various manners, including, but not limited 
to, sensing the setting of the transmission in the parking 
gear, the setting the parking brake, the lack of move- 
ment for a predetermined period of time, the opening 
and/or closing of a vehicle door or combinations of those 
events. In a preferred embodirrient, a parking state- is- 
sensed by the combination of the vehicle being placed 
in a parking gear and the driver-side door being opened 
and vehicle speed being equal to zero. In such preferred 
embodiment, the parking state sensors 202 would, 
therefore, include a parking gear sensor for sensing the . 
setting of the parking gear and a door sensor for sensing 
the opening and closing of the vehicle door. Other em- 
bodiments may contain varbus other methods for de- 
ckling that a user trip is over. For example the location 
of the vehicle at the port may be taken into account in 
order to determine that vehcle is in the parking state 
and the current trip has ended. There are several ways 
of determining that the vehicle is kx^ated at a port. The 
vehcle kx^atkxi system may place the vehicle at the 
port, the vehicle kientity may- be read at the entry gate • 
to the port for instance by tripping a switch that nray 
cause the vehcle kJentity to be read. The reading of a 
vehcle identity may also occur by sensors located at the 
vehcle parking spaces, or at the entrance to the parking 
bt. In addition placing a vehicle in park in a parking 
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space and opening the door may signal the end of the 
trip, or a user nr^y directly enter that the trip is over on 
the vehicle console. There is a great variety of flexibility 
in methods of deciding that a vehicle is in the parking 
state and the exact method chosen will depend on the 5 
implementation. 

[0086] In yet further embodiments of the invention in 
which vehicles in the fleet include electric powered ve- 
hicles, the vehicle subsystem for each electric powered 
vehicle Includes a state of charge SOC monitor 204 for io 
monitoring the available charge remaining in the vehi- 
cle. Data representing the SOC is provided to the proc- 
essor 188, for transmission to the central station 12 by 
the transmitter/receiver 190 for use vehicle allocation 
and monitoring functions described atxwe. Data repre- is 
senting other parameters 207^ such as vehicle speed, 
door open, vehicle charging, and so forth are also pro- 
vided to the processor 188, for transmission to the cen- 
tral station 1 2 by the transmitter/receiver 190. 
[0087] In yet further embodiments, the vehicle sub- 20 
system includes a vehicle location or tracking system. 
Such systems are known in the art. Vehcle locatkxi may 
be tracked through a variety of methods, the vehicle it- 
self can employ triangulation using radio beacons or 
dead reckoning, the vehrcle may also be tracked by re- ^5 
ceiving a signal from the vehcle and triangulating on 
that signal. In one further embodiment a GPS device 
206 provides location information to the processor 188, 
for transmissbn to the central station 1 2 ar»d/or for pro- 
viding on-board tracking and route planning data. The 30 
choice of tracking system, however is a matter of imple- 
mentatkxi conveniertce. 

[0088] The foregoing descriptkxi of the preferred em- 
bodiment of the invention has been presented for the 
purposes of illustratbn and description. It is not intended ss 
to be exhaustive or to limit the inventkxi to the precise 
form disck)sed. Many modificatkxis and variatiorts are 
possible in light of the. above, teaching. For example,. . 
while nnany of the data processing and decision making 
functkxis are described above as being performed by 40 
the central facility, other embodiments nr^ay include port 
facility computer substystems that are programmed to ^ 
perfomi some of such functkxis; In yet further embodi- . 
ments, .the vehrcle susbsystem may be programmed to 
perform some of such functions. Therefore, it is intended ^ 
tfiat the scope of the inventkxi be limited not by this de- 
tailed descriptbn, but rather by the clainns appended 
hereto. 



Claims 

1. A vehrcle sharing system, comprising: , . 

at least one port including a parking space and ss 
a terminal for accepting a request to use a ve- 
hicle; and 

a control center including a computer unit for 



processing sakJ request and allocating a vehi- 
cle to each request; 

wherein said request includes an estimated 
distance and time duration of an intended trip. 

2. A vehicle sharing system, according to claim 1, 
wherein said terminal includes a display of a map 
of a servk;ed area, and said estimated distance of 
an intended trip is indicated by selection of a zone 
defined in sakJ map. 

3. A vehicle sharing system, according to claim 2, 
wherein each shared vehicle is provided with a GPS 
which provides locatk>n information to a vehrcle op- 
erator according to the selection of the zone when: 
making the request. 

4. A vehk:le sharing system, according to claim 1, 
wherein sakj terminal includes a display device and 
is programmed to display the kjentrty of the allocat- 
ed vehicle. 

5. A vehicle alkx:ation system for allocating one or 
more vehicles from a fleet of vehicles to one or more 
users, the vehicle allocatkxi system comprising: 

one or more ports at geographically remote k>- 
cations relative to each other, each port having 
a user interface temninal for receiving user-in- 
put thfomnatton; 

at least one central statkxi computer system 
coupled for communication with the user inter- 
face terminal at each port for receiving user-in- 
put informatkxi from any of said user interface 
terminals, wherein sakj at least one central sta- 
tion computer system is programmed to select 
and allocate a vehicle from the fleet in response 
to receiving user-input information from a user, 
saki selection being based on the received us- 
er-input information. 

6; A system as recited in claim 5, whereiri each user- 
interface terminal comprises a display device for 
displaying a map to the user and a user-display in- 
terface for receiving user-selected map locations 
corresponding to locatkxis on the displayed map 
from a user. 

7. A system as recited in claim 5, wherein each user- 
interface terminal comprises: 

a computer programmed to control. the display 

devk:e to display a map with at least one of pre^: 

defined zones and map locations; and 

a user interface devk:e for allowing a user to 

select at least one of the predefined zones and 

kx:atkxis. 
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8. A system as recited in claim 7, wherein said user 
interlace device comprises at least one of a touch- 
screen, a keytx>ard, or a cursor controller. 

9. A system as recited in claim 5, wherein each port 
irK;ludes a display device to display the identity of 
the allocated vehicle to a user that inputs request 
information. 

10. A vehicle allocation system as recited in claim 5, 
wherein said user-input information comprises time 
of use information corresponding to a time period 
for which the user desires to use one of the vehicles 
from the fleet of vehicles. 

11. A vehicle allocation system as recited in claim 5, 
wherein said user-input information corrtprises dis- 
tance information corresponding to a distance 
which the user desires to travel with one of the ve- 
hicles from the fleet of vehicles. 

12. A vehicle allocation system as recited in claim 11 , 
wherein said user-input information further com- 
prises time of use Information corresponding to a 
time period for which the user desires to use one of 
the vehicles from the fleet of vehicles. 

13. A vehicle allocation system as recited in claim 10, 
wherein said user-input information further includes 
destination port information for identifying the port 
at which the user desires as a destination and 
wherein said time of use information and said dis- 
tar>ce information comprise information corre- 
sponding to the time and distance beyond the time 
and distance required to reach the destination port. 

14. A vehicle allocation system as recited in claim 11. 
wherein said user-input information further irK:tudes: 
destination port information for identifying the port 
at which the user desires as a destination and 
wherein said time of use information and said dis- 
tance information comprise information corre- 
sponding to the time and distance beyond the time 
arxJ distance required to reach the destination port. 

15. A vehicle allocation system as recited in claim 12, 
wherein said user-input information further includes 
destination port information for identifying the port 
at which the user desires as a destination and 
wherein said time of use information and said dis- 
tance infomration comprise information corre- 
sponding to the time and distance beyond the time 
and distance required to reach the destination port., 

16. A vehicle allocation system as recited in claim 5, 
wherein the vehicles in the fleet of vehicles are elec- 
tric powered and each vehicle defines a state of 
charge (SOC) at any given time, the vehicle alloca- 



tion system further comprising: 

a plurality of vehicle computer systems asso- 
ciated on a one-to-one basis with the vehicles from 
the pool of vehicles, each vehicle computer system 
s including means for detecting the SOC of its asso- 
ciated vehicle and for communicating a detected 
SOC to said at least one central station computer; 

wherein said at least one central station com- 
puter system is programmed to further base the se- 
10 lection of a vehicle on the detected SOCs of any 
vehicles located within the VSG of a port from which 
user-input information is received. 

17. A vehicle allocation system as recited in claim 5, 
15 wherein: 



each port has a vehicle search group (VSG) in 
which more than one and less than all of the 
vehicle from the fleet may be located at any giv- 
en time; and 

said central station computer is programmed to 
select and allocate a vehicle from the VSG of 
the port from which user-input infornnation is re- 
ceived. 
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18. A system as recited in claim 17, wherein each port 
includes a vehicle parking facility at which one or 
more vehicles may be parked at any given time and 
the VSG of a given port includes vehicles parked at 

30 a parking facility at the port. 

19. A system as recited in claim 18, wherein the VSG 
of a given port further includes vehicles due to arrive 
at the port within a preset time period. 
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20. A method for allocating one or more vehcles from 
a fleet of vehicles to one or nDore users, the method 
comprising: 

. providing at least one port terminal, each hav- 
ing a user interface for receiving vehicle re- 
quests from users; 

receiving a request for a vehicle at one of said 
port terminals from.one of sakJ users, said re- 
quest including user-input informatk^n; 
commun eating the user-input information to a 
central computer system; 
selecting a vehicle from the fleet and alkx:ating 
the vehicle to the request, saki selectkxi being 
based, at least in part, on the user-input infor- 
matkxi received at that port terminal. 



21... A method as recited in claim 20i.whereiasakJ step 
of provkiing at least one port terminal comprises- k>- - 
55 eating a plurality of port terminals at geographk^lty 
remote kx:atkxis relative to each other, wherein 
each port terminal is coupled for communication 
with the central computer system. 
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22. A method as recited in claim 20, wherein said step 
of receiving a request tor a vehicle comprises: 

displaying a map to the user; and 
receiving user-selected nnap locations corre-- 5 
sponding to locations on the displayed map 
through a user-interface associated with the 
displayed map. 

23. A method as recited in claim 20, wherein said step io 
of receiving a request for a vehicle comprises: 

displaying a map with at least one of predefined 
zones and map locations; and 
receiving user-selected zone or map locations 7S 
through a user interface device. 

24. A method as recited in claim 23, wherein said user 
interface device comprises at least one of a touch- 
screen, a keyboard, or a cursor controller. 20 

25. A method as recited in claim 20, further comprising 
the step of displaying the identity of a selected ve- 
hicle on a display device at the port terminal, to in- 
form the user of the selected vehicle. 2S 

26. A method as recited in claim 20, wherein said user- 
input information comprises time of use infomrration 
corresponding to a time period for which the user 
desires to use one of the vehicles from the fleet. 30 

27. A method as recited in claim 20, wherein said user- 
input information comprises distance information 
corresponding to a distance which the user desires 

to travel with one of the vehicles from the fleet. 3S 

28. A method as recited in claim 27, wherein said user- 
input information further comprises time of use in- ^ 
formation corresponding to a time period for which 
theuserdesirestouseoneof the vehicles from the ^ 
fleet of vehicles. 



reach the destination port 

31 . A method as recited in claim 28, wherein said user- 
input information further includes destination port 
information for identifying the port at which the user 
desires as a destination and wherein said t»ne of 
use information and said distance information com- 
prise information corresponding to the time and dis- 
tance beyond the time and distance required to 
reach the destination port. 

32. A method as recited in claim 20, wherein the vehi- 
cles in the fleet of vehicles are electric powered and 
each vehicle defines a state of charge (SOC) at any 
given time, the method further comprising detecting 
the SOC of vehicles in the fleet of vehicles and 
wherein said step of selecting a vehicle based on. 
the user-input information received at the port ter- 
minal comprises further basing the selection on the 
detected SOCs of the vehicles. 

33. A method as recited in claim 20, further comprising: 

defining a vehicle search group (VSG) for the 
port terminal at which user-input information is re- 
ceived from a user, wherein more than one and less 
than all of the vehicle from the fleet may be located 
in the VSG at any given time; 

wherein said step of selecting a vehicle from 
the fleet comprises selecting a vehicle from the 
VSG of the port at which user-input information is 
received from a user. 

34. A method as recited in claim 33. wherein the VSG 
of any given port terminal includes vehicles parked 
at a parking facility at the port terminal. 

35. A method as recited in claim 33, wherein the VSG 
- ■ .■ of any given port terminal further- includes vehicles 

due to arrive at the port terminal within a preset time 
period. 



29. A method as recited in claim 26, wherein saki user- 
input information further. includes destination port 
informatkxi for klentifying the port at which the user ^ 
desires as a destinatkxi and wherein said time of 
use information and saki distance information conrv 
prise information corresponding to the time and dis- 
tance beyond the time and distance required to 
reach the destination port. 



30. A method as recited in claim 27, wherein saki user- 
input, infornratkxi further includes destination port . . . . 
informatkxi for kientifying the port at which the user- 
desires as a destinatkxi and wherein said time of 55 - 
use informatkxi and sakJ distance informatkxi com- 
prise information corresponding to the time and dis- 
tance beyond the time and distance required to 
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